[MongoDB] AWS 3 Availability Zone 構成でのレプリカセットノード配置

こんにちは、菊池です。

以前、こんな記事を書きました。

[MongoDB] AWSにおけるレプリカセット構成の配置パターン

上記の記事執筆時点では、AWS東京リージョン（ap-northeast-1）では一部のユーザを除き2つのアベイラビリティゾーンしか利用することができませんでした。しかし、先日のアップデートで新しいアベイラビリティゾーン、ap-northeast-1dが利用可能になり、全てのユーザで3つのAZが利用できるようになりました。

東京リージョンの新しいアベイラビリティゾーン「ap-northeast-1d」がリリースされました。

ということで、3つのアベイラビリティゾーン環境でのMongoDBのベストプラクティス、移行方法を紹介します。

3つのアベイラビリティゾーン（AZ）を使ったノード配置

冒頭の記事でも紹介した通り、MongoDBのレプリカセットでは3つのノードを配置するのが最もオーソドックスな構成です。そのため、3つのAZが利用可能な環境では、AZごとに1つずつ分散して配置するのが理想的です。

よくあるELB（ALB） - WEB/APサーバ - MongoDBという構成の場合には以下のような配置パターンとなります。

ALB、WEB/APサーバ、DBとも3つのAZに分散したバランスの良い構成です。

一方で、WEB/APサーバは2つのAZへの分散配置で十分ということもあるでしょう。その場合には、以下のようなMongoDBのみ3つのAZへ分散配置した構成もありえます。

この場合に注意するのは、アクセスするサーバが存在しないAZ（上記の場合にはap-northeast-1d）のMongoDBがPrimaryに昇格しないようにすることです。AZを跨いだアクセスでは、通信レイテンシが大きくなりますので、ap-northeast-1dのノードがPrimaryに昇格すると、書き込み時のアクセスが必ずAZを跨ぐことになり、無駄なレイテンシを常に発生させることになります。それを回避するには、ap-northeast-1dのノードでPriorityを0に設定することで、Primaryへの昇格を回避することができます。

3AZ構成への移行

現在2つのアベイラビリティゾーンでレプリカセットを構成している場合の、3AZ構成への移行方法を紹介します。

まずは3つ目のAZにサブネットを作成し、EC2にMongoDBをインストールします。Primaryノードでrs.addコマンドを使い、レプリカセットに追加しましょう。priority: 0としておくことで、Primaryへの昇格を抑止しています。

PRIMARY> rs.add( { host: "追加対象のホスト名またはIPアドレス:27017", priority: 0 } )

この時点で、4ノードのレプリカセットクラスタになります。追加したノードには、自動でデータの同期が行われます。

続いて、不要となるノードをクラスタから削除します。Primaryノードでrs.removeコマンドを使います。

PRIMARY> rs.remove( { host: "削除対象のホスト名またはIPアドレス" } )

あとは不要になったEC2を停止・削除すれば完了です。

最後に

以上です。

全てのユーザで3つのAZが利用可能になったことで、3ノードクラスタを標準とするMongoDBのノード配置がシンプルになったと思います。もちろん、これまで通り2AZ構成という戦略も十分にありです。いずれにせよ、選択肢が増えることは嬉しいですね。